Mobile device server

ABSTRACT

A mobile device server includes a flexible architecture having a plurality of components for allowing various mobile devices and protocols to communicate with each other and to receive data from various information spaces. Interface devlets send and receive messages in respective protocols. Access infolets utilize respective access methods to provide an abstract view of various information spaces. Logic applets implement service and/or application logic by processing information from one or more infolets. A further component referred to as a let engine communicates with the devlets, infolets, and applets, and maintains user and device profile information to provide a flexible framework for the mobile device server that can readily support new devices and protocols.

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority from U.S. patent applicationSer. No. 09/853,151, filed on May 10, 2001, which claims priority fromU.S. Provisional Patent Application No. 60/248,816, filed on Nov. 15,2000.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH

[0002] Not Applicable.

FIELD OF THE INVENTION

[0003] The present invention relates generally to communication systemsand, more particularly, to portable wireless communication systems.

BACKGROUND OF THE INVENTION

[0004] As is known in the art, wireless Internet access is differentfrom simply accessing the Internet wirelessly. Mobile wireless usershave different needs, motivations and capabilities from typical wirelineusers. For example, a mobile user is usually in a multi-tasking mode,e.g., accessing the Internet while attending a meeting or shopping inthe mall. Typical Internet accesses are bursty in nature (checking stockquotes, weather, or finding a nearby restaurant) and task-oriented.Thus, browser-centric applications and elaborate user interfaces are oflimited utility since a mobile user usually carries small devices suchas a cell phone or a Personal Digital Assistant (PDA) having relativelysmall displays. These personalized devices, which are typicallyidentified by a wireless network address such as a cellular phonenumber, provide mobile users with continuous access to the Internet.

[0005] Advances in wireless networking and messaging technologies havegiven mobile users many choices to access Internet contents andservices. Existing devices and protocols include PDAs, such as PalmPilots with Web Clipping, cell phones with wireless application protocol(WAP) or short message service (SMS), email devices, such as Blackberryand AT&T PocketNet, supporting Post Office Protocol 3 (POP3) and/or(Internet Message Access Protocol) IMAP, and America On Line (AOL)Instant Messaging (AIM).

[0006] While such devices and protocols can provide limited Internetaccess, differing devices and protocols do not communicate with eachother easily. Thus, business and individual mobile users must makechallenging decisions to obtain mobile access in a constantly changingenvironment. For example, employees of a particular company may need touse a single type of device to enable wireless communication between theemployees. However, one device type may not be optimal or desirable forthe duties each employee must perform.

[0007] It would, therefore, be desirable to provide wirelesscommunication for a variety of mobile device types and protocols. Itwould further be desirable to provide wireless communication with avariety of information spaces. It would also be desirable to readilysupport wireless communication for new devices and protocols.

SUMMARY OF THE INVENTION

[0008] The present invention provides a mobile device server forproviding communication with a variety of protocols and devices. Themobile device server provides a message gateway for allowing mobiledevices using a range of protocols and access networks to relay messagesto each other and to obtain information from a range of informationspaces. With this arrangement, a mobile user can readily communicatewith other mobile users having the same or different devices. A mobileuser can also obtain data from a wide range of resources, such as theInternet and databases. While the invention is primarily shown anddescribed in conjunction with portable mobile devices, it is understoodthat the invention is generally applicable to systems in which it wouldbe desirable for differing device types and protocols to communicatewith each other.

[0009] In one aspect of the invention, a mobile device server includes aplurality of components that cooperate to enable a mobile device tocommunicate with other mobile device types and with a variety ofinformation space types. In one embodiment, a mobile device serverincludes an engine component that communicates with the mobile servercomponents and maintains user profile information. The server includes aplurality of interface components each of which corresponds to aparticular device type or protocol, for example. A plurality of accesscomponents provide abstract views of respective information spaces, suchas websites, databases, and corporate information. Each of a pluralityof logic components processes information retrieved by one or more ofthe access components for transmission back to the requesting mobiledevice via the corresponding interface component.

[0010] The engine component communicates with the interface, access andlogic components and maintains user/device profiles. In one embodiment,the engine component communicates with the interface components in apredetermined format, translates aliased user commands, invokesappropriate logic and access components, and transcodes retrieved datainto a format based upon characteristics, e.g., display size, of therequesting device.

[0011] In an exemplary operation, a mobile device issues a request forthe latest stock price of a particular company. The mobile device has aparticular messaging client, such as America On Line's Instant Messenger(AIM). The mobile device communicates with the mobile device server viaan AIM interface component, which receives the request for stock dataand formats the request into a predetermined format. The enginecomponent receives the formatted request, validates the mobile useridentification, and transforms command aliases, e.g., q for “quote”.

[0012] The engine component then sends the data request to anappropriate logic component, which can for example, determine an optimumstock quote service based upon certain criteria. The logic componentthen requests the engine component to invoke the appropriate accesscomponent corresponding to the selected quote service, e.g., Yahoo. Theaccess component then utilizes the proper mechanism, e.g., Hyper TextTransfer Protocol (HTTP), to retrieve the requested content.

[0013] The retrieved raw content is returned to the engine component forexamination and formatting. The engine component accesses the profile ofthe recipient device to which the requested information is to be sent,which may or may not be the requesting mobile device. Based upon theprofile of the recipient device, the engine component invokes anappropriate access component for transcoding the retrieved raw contentinto the appropriate format, e.g., text only. The engine component thendelivers the transcoded data to the interface component corresponding tothe recipient device for transmission.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The invention will be more fully understood from the followingdetailed description taken in conjunction with the accompanyingdrawings, in which:

[0015]FIG. 1 is a schematic depiction of a mobile device server forcommunicating with a variety of devices and networks in accordance withthe present invention;

[0016]FIG. 2 is a schematic block diagram of an exemplary architecturefor the mobile device server of FIG. 1;

[0017]FIG. 3 is a schematic block diagram showing the mobile deviceserver having a plurality of interface devlets in accordance with thepresent invention;

[0018]FIG. 4 is a schematic depiction of an exemplary communication pathconfiguration for a mobile device server in accordance with the presentinvention;

[0019]FIG. 5 is a schematic block diagram showing the mobile deviceserver having a plurality of access infolets in accordance with thepresent invention;

[0020]FIG. 6 is a schematic block diagram showing a first part of a datatransfer by a mobile device server in accordance with the presentinvention;

[0021]FIG. 7 is a schematic block diagram showing a second part of adata transfer by a mobile device server in accordance with the presentinvention;

[0022]FIG. 8 is a schematic block diagram showing a third part of a datatransfer by a mobile device server in accordance with the presentinvention;

[0023]FIG. 9 is a schematic block diagram showing a fourth part of adata transfer by a mobile device server in accordance with the presentinvention;

[0024]FIG. 10A is an exemplary screen display showing Internet access offlight info from an AIM device through the AIM devlet on the mobiledevice server in accordance with the present invention;

[0025]FIG. 10B is an exemplary screen display showing website newsaccess from a Palm V device through the email devlet on the mobileserver in accordance with the present invention;

[0026]FIG. 11A is an exemplary screen display for a device accessing acorporate database through the JDBC infolet on the mobile device serverin accordance with the present invention;

[0027]FIG. 11B is an exemplary screen display for a mobile phoneaccessing a corporate database through the JDBC infolet on the mobiledevice server in accordance with the present invention;

[0028]FIG. 12 shows an exemplary screen display for a device requestingservice from a CORBA object through the AIM devlet on the mobile deviceserver in accordance with the present invention;

[0029]FIG. 13 is an exemplary screen display for a device controllingX10 home network devices through the AIM devlet on the mobile deviceserver in accordance with the present invention;

[0030]FIG. 14 is an exemplary screen display for a device accessing aninbox of an E-mail account through the AIM devlet on the mobile deviceserver in accordance with the present invention;

[0031]FIG. 15 is a pictorial representation of an applet for finding amovie for a mobile user of a mobile device server in accordance with thepresent invention; and

[0032]FIG. 16 is a schematic representation of an instant messagingmechanism for a mobile device server in accordance with the presentinvention.

DETAILED DESCRIPTION OF THE INVENTION

[0033] In general, the present invention provides a mobile device serverthat operates as a message gateway for allowing mobile devices usingvarious protocols on different access networks to communicate with eachother. The mobile device server also allows mobile clients to accessresources and information on the Internet and various other networks.The mobile device server includes a flexible architecture having aplurality of components that cooperate to service mobile devicecommunication requests. Mobile device server components include a letengine component communicating with interface devlets, logic applets,and access infolets. This arrangement allows the mobile device server toreadily support new devices and protocols by adding correspondingdevlets, infolets, and applets without altering the existing servicelogic.

[0034] As described more fully below, interface devlets receive and sendmessages through a particular protocol used by various mobile devices.Access infolets utilize particular access methods to provide an abstractview of respective information spaces. And access applets implementservice or application logic by processing information from one or moreinfolets. The let engine provides the basic framework for maintainingapplets, devlets and infolets, supporting user and device profiles forpersonalization and transcoding, and invoking proper applets andinfolets to answer data requests from devlets.

[0035]FIG. 1 shows an exemplary embodiment of a mobile device server 100for enabling mobile users to communicate with a variety of devices andprotocols in accordance with the present invention. The mobile deviceserver 100 can run on a computer 102 having connections to a pluralityof networks and devices. It is understood that the mobile device servercan operate on a variety of known computers and operating systems, suchas Unix and Windows. In one embodiment, the mobile device server 100 isimplemented using the Java programming language running in a Windowsenvironment.

[0036] The mobile device server 100 further includes a mobile phonedevice 104 for receiving and transmitting data via wirelesscommunication. The mobile phone 104 can support Short Message Service(SMS) communication, which is well known to those skilled in the art.While shown as a wireless phone coupled to the computer, it will bereadily apparent to one of ordinary skill in the art that mobile deviceserver functionality can be readily integrated into a single device. Inaddition, the mobile device server can include a number of wirelessdevices, which can be the same or different type, coupled to thecomputer 102.

[0037] The mobile device server 100 enables communication betweenvarious devices and networks. In the illustrated embodiment, a cellphone 200 with two-way short messaging service (SMS), e.g., a GlobalSystem for Mobile Communication/ Time Division Multiple Access(GSM/TDMA) phone connected to a GSM/TDMA network 202, can communicatewith the mobile device server 100 through an SMS driver hosted on themobile device server. Cellular Digital Packet Data (CDPD) devices 204,such as AT&T PocketNet phone 204 a and Palm V 204 b, coupled to a CDPDnetwork 206 can use a Wireless Access Protocol (WAP) gateway 208 toaccess the mobile device server 100 through the Internet 210. Emaildevices 214, such as a Blackberry mobile device, can use the StandardEmail Protocol (SMTP) on the CDPD network 206 or a two-way pagingnetwork 216 coupled to a mail server 218 to communicate with the mobiledevice server 100.

[0038] In addition, PC device users and some PDAs can use AOL InstantMessenger (AIM) or web browsers to communicate with the mobile deviceserver 100, which can support a Transmission Control Protocol (TCP)interface. Mobile devices can include an embedded module forcommunicating with the mobile device server 100 directly via the TCPinterface. The mobile device server 100 can receive messages andcommands from these devices, access Internet services and information onbehalf of a mobile user, and relay messages or Internet content back tothe sending devices or other devices, as described more fully below.

[0039] The mobile device server 100 includes an architecture having aplurality of interface, logic, and access components that enable themobile device server to communicate with a range of devices, protocolsand information spaces. This arrangement hides the complexity ofmultiple devices and content sources from mobile users. The mobiledevice server 100 can include a proxy server that provides anenvironment for hosting agents and personalized services, which can beimplemented as reusable building blocks in the Java programminglanguage, for example. An exemplary proxy server known as iProxy, isshown and described in U.S. patent application Ser. Nos. 08/974,600,filed on Dec. 19, 1997, and 09/474,914, filed on Dec. 30, 1999, whichare incorporated herein by reference. In general, an iProxy agent, whichcan include a web-server, can be invoked like a regular common gatewayinterface (CGI) program. The iProxy system also allows scripts embeddedinside web pages to invoke agents to perform specialized processing. TheiProxy system maintains user profiles and adds intelligence to thetraditional HTTP proxy server to provide personalized, and value-addedservices such as filtering, tracking, and archiving.

[0040]FIG. 2 shows an exemplary architecture for a mobile device server300 having a plurality of components that combine to provide a flexiblearchitecture that can readily support new devices, interfaces andinformation spaces. In one particular embodiment, the mobile deviceserver 300 includes interface devlets 302, logic applets 304 and accessinfolets 306. The devlet, infolet, and applets 302, 304, 306, as well asa proxy interface 308, communicate with each other through a let engine310. These components can be implemented as iProxy agents.

[0041] As shown in FIG. 3, each interface devlet 302 provides a protocolinterface to a given device on a particular access network. As describedabove, exemplary access network types include the Internet, CDPD, andGSM/TDMA, each of which is supported by one or more correspondinginterface devlets. In the illustrative embodiment, an AIM devlet 302 a,a GSM/TDMA devlet 302 b, a TCP/IP devlet 302 c, and a SMTP/IMAP devlet302 d are shown for communicating with the corresponding networks. It isunderstood that further interface devlets can be provided for a varietyof additional protocols well known to one skilled in the art. Forexample, email devlets can include SMTP, IMAP and POP3 devlets forsending and retrieving email.

[0042] The interface devlets 302 interact with the let engine 310 via apredetermined interface format. In one particular embodiment, thedevlets 302 provide requests to the let engine 310 in character-streamcommand lines and the let engine returns results in MultipurposeInternet Mail Extensions (MIME) format. After the mobile device server300 is initialized, each interface devlet 302 monitors a respectivechannel for incoming requests sent by a remote mobile device. Forexample, the AIM devlet 302 a on the mobile device server starts an AIMclient for listening to service requests from other AIM clients sent asinstant messages.

[0043] It is understood that the required device driver can form a partof a corresponding interface devlet 302 or can communicate with thedevlet through a TCP protocol, for example. This approach allows adevice driver to run on a remote machine, i.e., a device other than onthe mobile device server.

[0044]FIG. 4 shows an exemplary communication path between an SMS mobilestation MS and a mobile device server MDS in accordance with the presentinvention. An SMS devlet running on the mobile device server MDScommunicates with a GSM cell phone MS attached to a remote personalcomputer RPC through an SMS driver. Mobile users can send messages tothe cell phone MS (through the GSM network), which then forwards eachmessage to the mobile device server MDS for processing. The mobiledevice server MDS then returns the result to the mobile user through thesame channel. Such an arrangement is further shown and described in U.S.Provisional Application No. 60/206,167 entitled “Mobile Phone InternetAccess Utilizing Short Message Service Method and Apparatus,” filed May22, 2000, which is incorporated by reference herein.

[0045] Similarly, to allow access to the mobile device server throughemail, a mobile device server email devlet can monitor messages arrivingat a particular email account for new service requests. For TCP users, aTCP session is created upon receiving a request to connect with aparticular port of the mobile device server machine using the telnetprotocol. The telnet user can enter mobile device server commands as ifusing a typical Unix or Windows terminal, for example. The mobile deviceserver can also support the WAP and HTTP protocols through the proxyinterface 308 (FIG. 2).

[0046] Referring again to FIG. 2, while each protocol and device canhave unique interfaces, each corresponding interface devlet 302interacts with the let engine 310 in a predetermined format. Moreparticularly, a devlet 302 can send a data request in the form of acharacter stream, interpreted as an mobile device server command andassociated parameters, to the let engine 310. The devlet 302 can receiveresults from the let engine 310 in a Multipurpose Internet MailExtensions (MIME) format appropriate for the device, which is determinedby the corresponding device profile stored at the let engine. Deviceprofiles contain information for user devices, such as how muchinformation can be displayed.

[0047] A simplified version of the mobile device server command syntaxis listed below: <command> := [ <forward_command> <destinations> ]<applet_command> [<applet_argument> ]* <destinations> := <destination>[“,”<destination> ]* <destination>  := <protocol> “:”<account_id>

[0048] In this particular embodiment, the naming of each device ordestination follows the conventional URL naming scheme: protocol namefollowed by an account name or address. For example, typical destinationaddresses include “sms:+19735556242” (GSM cell phone), “aim:sunshineX”(AIM buddy name), “mail:iproxy@research.att.com (email id)”, etc.

[0049] As described more fully below, after receiving the command, thelet engine 310 invokes one or more logic applets 304 that implement therequired logic for the data request. The let engine 310 then invokes theaccess infolet 306 appropriate for the information space to be accessed.

[0050] Referring briefly to FIG. 5, the access infolets 306 extendbeyond the HTTP protocol and URL name space to provide abstract views ofvarious information spaces, such as databases 350, Internet informationsources 352, core networks 354, and X10 home devices. Correspondingaccess infolets, such as Java Data Base Connectivity (JDBC) 306 a, http320 b, CORBA 306 c infolets access the respective information spaces asshown. A given interface infolet 306 retrieves information from aparticular information space, such as stock quote sites, weather sites,and airline flight databases. It is understood that the same informationmay be accessed using a variety of access protocols. For example, suchinformation is commonly available on many websites, and may also beretrieved from XML files or databases. An interface infolet retrievesthe original content and returns it to an appropriate applet 304 forfurther processing, as described more fully below.

[0051] As an example of a mobile station request to access the stockprice of AT&T (stock symbol T), the mobile device user can issue a“quote T” command. If the request is sent by a mobile user using SMS onthe GSM network, then the result will be returned as plain text to therequesting GSM cell phone. If the mobile user wants to forward theresult to an email address, e.g., herman@research.att.com, the userissues a “forward mail:herman@research.att.com quote T” command. Sincethat email account understands the MIME type text/HTML (according to thedevice profile), the result will be sent by the let engine as an HTMLfile, complete with graphics, to the herman@research.att.com emailaccount.

[0052] The interface devlets 302 allow users on different networks toreadily communicate with each other. For example, if a GSM phone userwants to send a message to other devices, such as an AT&T PocketNet mailaccount, e.g., chen@mobile.att.net, which is on the CDPD network, and anAT&T TDMA phone having phone number 555-500-6531 using SMS, then an echoapplet can use a message relay service as follows: “forwardmail:chen@mobile.att.net, attmsg:5555006531 echo call your boss.”

[0053] FIGS. 6-9 show an exemplary transaction between a mobile deviceMS and a mobile device server 300 in accordance with the presentinvention. As shown in FIG. 6, the mobile device MS, such as a Palm Vxwith a CDPD modem having an AIM client, issues a “q T” (quote AT&T-stock symbol T) command, which requests that the mobile device server300 retrieve the current price of AT&T stock. The Palm Vx MS establishesa communication channel with the mobile device server 300 via an AIMdevlet 302 a, e.g., imobile4att. The AIM devlet 302 a receives theinstant message from the Palm Vx device and formats the message into apredetermined format, e.g., “q T” in text, prior to passing the messageto the engine component or let engine 310. The engine component 310transforms any aliases, e.g., q for quote, defined by the mobile deviceuser and authenticates the user. The engine component 310 then invokesthe appropriate logic applet 304 b, which can implement predeterminedlogic for selecting a stock quote service, such as MSN, Yahoo, Etrade,etc.

[0054] As shown in FIG. 7, the logic applet 304 b then requests the letengine 310 to invoke the appropriate, e.g., http, access infolet 306 a.In FIG. 8, the access infolet 306 a retrieves the request stockinformation using the mechanism, e.g., http, appropriate for theselected quote service. The infolet 306 a then returns the raw data,which can be in HTML format, to the let engine 310.

[0055] As shown in FIG. 9, the let engine 310 examines the raw data, aswell as profile data for the recipient device, which can be the same ordifferent from the requesting mobile device MS. For example, the mobiledevice MS can request data to be forwarded to a specified device, suchas an email account. Based upon the profile of the recipient device, thelet engine 310 can send the raw data to a transcoding infolet 306 b forprocessing. In the case where the recipient device accepts only text inmessages less than 1000 bytes, the transcoding infolet 306 b transcodesthe raw data accordingly. After the infolet converts the data into text,the let engine 310 then delivers the text message to the AIM devlet 302a, if the Palm Vx device MS is the recipient device.

[0056] It is understood that the mobile device server of the presentinvention can communicate with a wide variety of mobile device types. Inaddition, the architecture of the mobile device server can readilysupport new functionality with applets, new devices with devlets, andnew information spaces with infolets.

[0057]FIG. 10A shows an AIM client, mingfengchen, on an exemplary mobiledevice that talks to the mobile device server AIM agent, mfchen4iproxy.The AIM client issues the “flight 001 ” command to get flightinformation on a particular airline and receives output including timeand gate information for each leg of the flight. Mapping from the flightcommand to the airline can be controlled by a corresponding logic appletaccording to the user profile. Also, the let engine invokes necessarytranscoding services to map the elaborate content on the airline websiteto the receiving device according to AIM device's profile.

[0058]FIG. 10B shows a Palm V device having an Omnisky modem that justsent an email to the mobile device server email devlet atimobile@research.att.com with the command “sitenews att.” This commandinstructs the mobile device server to access the service provided byAT&T's Website News, which reports new hyperlinks on AT&T's website(http://www.att.com). The result is sent back as an email formatted forthe Palm V device.

[0059]FIG. 11A shows a mobile user connecting to an enterprise databasethrough an AIM client to find contact numbers for a particular softwareapplication using the mobile device server of the present invention.FIG. 11B shows how to access the same information from a cell phone thatsupports the WAP protocol. Corporate Information is typically accessedthrough JDBC and ODBC interfaces. The mobile device server includes aJDBC infolet that allows mobile users to access enterprise databaseinformation (marketing/sales data, system interface, etc.) throughSQL-like queries.

[0060] Network/Infrastructure Resources are typically accessed throughthe CORBA (Common Object Request Broker Architecture) interface. Asknown to one of ordinary skill in the art, CORBA is an architecture andspecification for managing distributed program objects in a network toallow programs at different locations to communicate through an“interface broker.” The mobile device server hosts a CORBA infolet thatallows mobile users to request services from CORBA objects. FIG. 12shows how an AIM user gets phone diversion information for the userHerman.

[0061]FIG. 13 shows a mobile device user controlling X10 devicesremotely via the mobile device server of the present invention. The X10home network technology allows lamps and appliances connected on thesame power line to be controlled by a computer. The mobile device serverhosts an X10 infolet that controls home network devices connected to itsserver machine. First, the user instructs the mobile device server tolocate the firecraker, the device that is capable of sending a radiosignal to a transceiver device on the X10 network, through the serialport COM2 on the mobile device server host. After the connection isestablished, a command, e.g., “x10 on a1” is sent to turn on the fan(which is named device al on that particular X10 network) and “x10 ona2” to turn on the coffee pot. The X10 interface allows a mobile user tocontrol the lighting and appliances at home with a GSM cell phone, anAIM client, or an email device anywhere in the world. The X10 infoletalso demonstrates that an infolet can be used to both retrieve andchange the state of an information space. An applet based on X10infolets can use an algorithm to determine when and how to activatecertain X10 infolets to control a home environment.

[0062] Further application for utilizing the mobile device server toaccess home network devices will be readily apparent to one of ordinaryskill in the art. For example, motion sensors can be activated andde-activated using a mobile device, such as a cell phone. A user caninstruct a recording device to tape a television program using themobile device server. It is understood that a variety of devices can beused to access a home network. That is, a user can utilize any of a cellphone, PC, PDA, Palm device, etc. to manipulate home network devices. Itis further understood that while the mobile device server is primarilydescribed as supporting mobile devices, non-mobile devices such asdesktop PCs can communicate with the mobile device server.

[0063]FIG. 14 shows a mobile user accessing an email account via amobile device server in accordance with the present invention. Themobile user first checks the status of the inbox to find the number ofunread messages. The mobile device server supports an IMAP infoletcalled inbox that can query and view a user's email account. The mobileuser can look at the size, e.g., 728 bytes, subject, and sender of thatmessage before actually viewing it. Such interaction is advantageous fora mobile user with limited bandwidth and screen space on a mobiledevice.

[0064] As described above, an applet implements business, service, orapplication logic by processing contents from different sources andrelaying results to various destination devices. A simple applet is the“echo” applet described above, which sends a message from one device toanother without using any information sources. It is understood that anapplet can also have relatively complex interactions with otherinfolets.

[0065] As showin in FIG. 15, for example, a FindMeAMovie applet can beimplemented as an iProxy script as shown below. #!/iproxy/script # getthe localtion information (zip) :javabin infoLet zip getlocation # gettop 10 movies (mlist) :javabin infoLet mlist top 10 movie :foreachmtitle $ {mlist} # Find theaters -- Movie: ${mtitle} -- :javabin infoLetthlist findTheater ${mtitle} ${zip} :foreach theater ${thlist} # Listthe title & theater ${theater} :endfor :endfor

[0066] This applet finds theaters near a cell phone user that arecurrently showing the top ten movies by executing the followingsteps: 1) find out the location (zip code) of the cell phone user, 2)find the top 10 movies from a movie database or website, 3) for each ofthese movies, find out if any local theater shows that movie, and 4)list the move title and the theater.

[0067] In general, each devlet, infolet, and applet must be registeredat the let engine first before communications with other agents canoccur. Each abstract device that communicates with the mobile deviceserver must register its profile information with the let engine first.A device name is designated by protocol and account ID, i.e.,protocol:acct_id. For example, an AIM user webciao is named aim:webciao.The mobile device server maintains a default profile for each devicetype, and each instance of a device can overwrite that profile withdevice-specific information. A device profile can simply be a list ofattribute-value pairs. An important attribute is dev.format.accept,which determines what MIME type the device is allowed to accept. Thisinformation is used by the mobile device server to transcode originalcontent to a format appropriate for this device, as described above. Forexample, the default profile for an email device is the following andcan be named mail.ini in the directory in which device profiles arekept: dev.format.accept=text/html,*/* dev.page.size=−1

[0068] The above device profile indicates that the default MIME type istext/html, but all MIME types(*/*) are acceptable. Also, the page size“−1” indicates that there is no limit on the size of each messagetransmission. These values are inherited by all mail devices unless theyare overwritten. For example, while the two default values might bevalid for primary email devices (desktop or laptop PC's), they are notappropriate for emails used on cell phones, such as AT&T's PocketNetphone. The following device profile for a PocketNet phone indicates thatonly the MIME type text/plain is appropriate for this device and that itdoes not accept messages longer than 230 characters:

dev.format.accept=text/plain dev.page.size=230

[0069] A devlet can require additional information that tells the mobiledevice server how and when to access this device. For example, thefollowing profile for the address imobile@research.att.com, used by theemail devlet of the mobile device server, specifies the frequency (every10 seconds) of checking the email account (store.checktime), the accountpassword (store.url), the transport protocol for sending email(transport.url), last time the user accessed the account (cmd.lasttime),etc. mail. store.checktime=10000 mail.store.url=imap://imobile:password@bigmailmail.transport.url=smtp://bigmail . . .

[0070] In general, each device is mapped to a registered user of themobile device server. Significant reasons for this mapping arrangementinclude limiting access to legitimate users of the mobile device server;and personalizing a service based on the user profile. An illustrativedevice-to-user map stored in the server (rarp.ini) is set forth below:sms:+886935551826=herman sms:+19085556842=chenmail:dchang@research.att.com=difa aim:webciao=chen . . .

[0071] It is understood that the mobile device server of the presentinvention can rely upon a variety of authentication techniques. Sincethe mobile device server interacts with multiple networks and protocols,the server relies on different authentication mechanisms. In oneembodiment, the mobile device server uses the cell phone identificationon wireless phone networks, AOL buddy names on the AIM network, andgeneric user ID and password information for WAP, HTTP, and telnetclients. However, the mobile device server itself does not have controlover the security afforded by some of these networks. Alternativeembodiments can include the SSH Secure Shell to provide end-to-endauthentication services. In general, the technique used by the mobiledevice server to authenticate a mobile user depends on the device orprotocol used. Trusting wireless networks, such as Voicestream/GSM andAT&T TDMA networks, to provide the correct cell phone id when a shortmessage (SMS) is received is generally acceptable unless a cell phone isstolen and the user did not lock the phone with a security password. Themobile device server can also trust the AOL network authentication fornon-critical services. User authentication through the mobile deviceserver itself is required if the user accesses the mobile device serverthrough telnet, WAP, or HTTP. Following is a typical and simple userprofile: name=Robin Chen password=xf2gbH3 default=$mail.1 # my addressessms.1=sms:+19085556842 mail.1=mail:chen@research.att.commail.2=mail:imobile@mobile.att.net mail.all=$mail.1,$mail.2aim.1=aim:webciao # command aliases sms.cmd.q=quote sms.cmd.sn=sitenews# address aliases sms.addr.cc=aim:chrischen

[0072] This user profile stores the user name, password, and a list ofthe devices that the user registers with the mobile device server. Italso stores command and address aliases. When a user accesses the mobiledevice server through AIM using the id webciao, the mobile device serverdetermines from the user-device map that the user is chen and uses theuser profile chen.ini for all later service requests from this device.For example, the following short message sent from a GSM phone: “forward$mail. 1 q T” is interpreted as “forward mail:chen@research.att.comquote T” according to the user profile. The special character “$”requests that the mobile device server map the named device, i.e., mail.1, to its corresponding entry in the profile.

[0073] In a further embodiment, the mobile device server supports eventdriven message generation to one or more users. In general, a user isconsidered to have previously requested such information when thepredetermined event occurs. For example, in the event that a child isabsent from school a message is sent to the parents cell phone. Themessage can be sent to a plurality of devices associated with the parentto ensure that the message is noticed. In addition, messages can beschduled for delivery at predetermined times. For example, a schedulerapplet can periodically check for scheduled events. For example, themobile device server can send a message to a device at a predeterminedtime to alert a person that a daily medication should be taken. It isunderstood that a user can be mapped to multiple devices in the userprofile. For example, a user can add to a daily journal located in a oneaddress location via multiple devices, such as a cell phone, PDA, andPC.

[0074]FIG. 16 shows an exemplary embodiment of mobile device servercomponents for supporting an instant messaging mechanism among aplurality of devices. In one embodiment, the instant messaging mechanismincludes a talkto applet 400, a session ID applet 402, and a talkoverapplet 404. The talkto applet is invoked by the engine component 406 inresponse to a users request for instant messaging with another device,which can be of the same or different type. The engine component thengenerates the session ID applet 402 for providing a session ID to eachdevice participating in the instant messaging. The name of the appletcorresponds to the session ID, which is shared by the instant messagingusers. The talkover applet 404 terminates parties from the instantmessaging session. When all of the parties have left the session, thesession ID applet 402 ceases to exist.

[0075] One skilled in the art will appreciate further features andadvantages of the invention based on the above-described embodiments.Accordingly, the invention is not to be limited by what has beenparticularly shown and described, except as indicated by the appendedclaims. All publications and references cited herein are expresslyincorporated herein by reference in their entirety.

[0076] What is claimed is:

1. A mobile device server system for processing data requests from avariety of mobile device types, comprising: an engine component; aplurality of interface components communicating with the enginecomponent in a predetermined format, each of the plurality of interfacecomponents for providing a respective interface for mobile devicessending data requests; a plurality of access components communicatingwith the engine component, each of the plurality of access componentsfor providing an abstract view of a respective information source typebased upon the data requests; and a plurality of logic componentscommunicating with the engine component, each of the plurality of logiccomponents for processing information retrieved by the plurality ofaccess components and providing the processed information to one or moreof the plurality of interface components for transmission.
 2. The systemaccording to claim 1, further including a proxy interface for providinga communication interface to the mobile device server.
 3. The systemaccording to claim 1, wherein the plurality of interface componentsincludes components for supporting protocols selected from the groupconsisting of supporting interfaces to AIM, ICQ, SMS, XMS, Telnet, HTTP,WAP, SMTP, IMAP, POP3, and IVR.
 4. The system according to claim 1,wherein the plurality of access components includes components forproviding access to information spaces selected from the group of accesscomponents consisting of ODBC, JDBC, CORBA, http, X10, email, and XML.5. The system according to claim 1, wherein the predetermined formatincludes text for transfers from the plurality of interface componentsto the engine component.
 6. The system according to claim 5, wherein thepredetermined format includes MIME for transfers from the enginecomponent to the plurality of interface components.
 7. The systemaccording to claim 1, wherein the variety of mobile device types includedevices selected from the group consisting of SMS mobile phones, PDAdevices, Instant Messaging devices, Email devices, two way pagers,pocket PCs, and AT&T Pocket Net devices.
 8. The system according toclaim 1, wherein the mobile devices can communicate with one or more ofCDPD, TDMA, GSM, two way paging, Internet, and email networks.
 9. Thesystem according to claim 1, further including a logic component forre-directing the processed information to a further device associatedwith the first mobile device.
 10. The system according to claim 1,further including a logic component for scheduling an activation and/orresponse to a data request.
 11. A method for enabling communicationbetween a variety of mobile device types, comprising: receiving a firstdata request from a first mobile device utilizing a first protocol;receiving a second data request from a second mobile device utilizing asecond protocol; formatting the first and second data requests into apredetermined format; processing the first data request to initiate aninformation exchange between the first mobile device and a firstinformation space associated with a first information source; retrievingrequested data for the first data request from the first informationsource; formatting the retrieved data based upon parameters associatedwith the first mobile device; and sending the formatted data to thefirst mobile device using the first protocol.
 12. The method accordingto claim 11, further including supporting an additional type of mobiledevice by adding an interface component supporting the additional mobiledevice type.
 13. The method according to claim 11, further includingsupporting an additional type of information space by adding an accesscomponent supporting a protocol for accessing the additional type ofinformation space.
 14. The method according to claim 11, furtherincluding supporting an additional service function by adding a logiccomponent supporting the additional service.
 15. A method for adding newcomponents to a mobile device server having a flexible architecture,comprising: providing an engine component; providing a plurality ofinterface components communicating with the engine component in apredetermined format, each of the plurality of interface components forproviding a respective interface for mobile devices sending datarequests; providing a plurality of access components communicating withthe engine component, each of the plurality of access components forproviding an abstract view of a respective information source based uponthe data requests; providing a plurality of logic componentscommunicating with the engine component, each of the plurality of logiccomponents for processing information retrieved by the plurality ofaccess components and providing the processed information to one or moreof the plurality of interface components for transmission to the mobiledevice that sent the data request; and adding a further one of aninterface component, access component and a logic component to support arespective mobile device, information source, and process withoutaltering service logic of the mobile device server.
 16. A method forservicing data requests by a plurality of mobile device types,comprising: receiving a data request from a first mobile device via arespective one of a plurality of interface devlets; formatting the datarequest to a predetermined format; passing the formatted data request toa let engine; invoking at least one of a plurality of logic appletsbased upon the data request; invoking a respective one of a plurality ofaccess infolets based upon an information space type associated with thedata request; retrieving raw data from a device corresponding to theinformation space type; formatting the raw data based uponcharacteristics of a recipient device specified in the data request; andpassing the formatted the data to the recipient device via an interfacedevlet supporting the recipient device.
 17. The method according toclaim 16, further including formatting the data request into text. 18.The method according to claim 16, further including formatting the rawdata into MIME.
 19. The method according to claim 16, wherein thecharacteristics of the recipient device include a size limitation. 20.The method according to claim 16, further including servicing datarequests from devices including at least two device types selected fromthe group consisting of SMS mobile phones, Palm devices, AIM devices,AOL devices, two way pagers, pocket PCs, and AT&T Pocket Net devices.21. The method according to claim 16, further including supporting anadditional type of mobile device by adding a corresponding interfacedevlet without altering service logic.